1. Field of the Invention
The present invention relates to an Application Programming Interface (API) that allows platform independent plug-ins to work with native web browsers.
2. Background Art
Plug-ins are software modules that extend functionality of a web browser. A common use of plug-ins is to extend the browser support for specialized content such as animation. As browser makers cannot account for all the types of content that are used on the web, plug-ins provide a mechanism for content makers to create software modules that enable browsers to display the specialized content. For example, a certain software company may create a new animation format for viewing on the web. The software company then must create a plug-in designed to allow browsers to view the new animation format. When a user encounters the animation format on a web page, he must download the plug-in and install it before he can view the animation on his browser.
Plug-ins are created to fit uniquely the browsers to which they are being installed. For example, a plug-in made for Internet Explorer™ will not work for Netscape Navigator™. Furthermore, a plug-in made for the Windows version of Netscape Navigator™ will not work with the Solaris™ operating system version. Because of this, software programmers implementing plug-ins must be concerned with the details of all browser types, making plug-in development difficult and non-portable.
To overcome this limitation, there is a mechanism that allows programmers to develop plug-ins using a platform independent programming language such as Java™. Developing in Java™ allows plug-ins to be developed for all types of browser for which a Java™ interface has been created. Using Java™, programmers do not need to create different versions of a plug-in for different platforms (the different types of browser and the computer systems on which they execute are collectively referred to as platforms). Although this technique offers considerable improvement, it still has shortcomings. Before further discussing the shortcomings, an overview of platform independent programming language is provided.
Platform Independent Programming Language
Traditionally each type of computer operating system requires programmers to develop software in a certain set of unique programming languages. As a large number of computers become inter-connected via the Internet, the diversity of computer system (platform) creates a need for a platform independent programming language that runs on all platforms. A platform independent programming language allows computer programmers to develop programs that execute without regard to the execution platform.
An example of a platform independent programming language is Java™. Java™ differs from other programming languages in how programs are compiled and executed. In other programming languages programs are usually compiled into machine-dependent executable code. For example, a program written for an Unix system is compiled into executable code used specifically by an Unix system. The compiled code cannot be executed on another system. In Java™, programs are compiled into platform independent bytecode classes. These byetcode classes contain code and data in a platform independent format called the class file format. The platform independence in Java™ is achieved by having a uniform execution agent called a virtual machine. In Java™, the virtual machine takes on the responsibility of executing the compiled bytecode classes by translating them into platform-specific instructions and sending the instructions to the underlying computer system. This shields the classes from having to interact with the underlying computer platform. Thus the classes can be executed on any platform, as long as a virtual machine is present.
Sample Network Application Environment
One common application of a platform independent programming language such as Java™ is its usage in a networking environment. FIG. 1 is a block diagram illustrating a sample network application environment such as a Java™ network application environment. This diagram helps one understand how platform independent programs are created and executed in a network environment such as the Internet. Such an environment comprises of a client platform 102 coupled over a network 101 to a server 100 for the purpose of accessing class files for execution of a software application or applet. An applet is a smaller application, written in Java™, that is commonly downloaded and executed across a network.
In FIG. 1, server 100 comprises development environment 104 for use in creating the source files for a given application. The development environment 104 provides a mechanism, such as an editor and an applet viewer, for the programmer to generate source files and preview applets. A set of core classes 103 comprise a library of commonly used functions that the programmer can reference. From development environment 104, the programmer creates one or more source files 105. Source files 105 contain class definitions, including data structures, method implementations and references to other classes. Source files 105 are provided to compiler 106, which compiles source files 105 into compiled “.class” files (or class files) 107 that contain bytecodes executable by a virtual machine. Bytecode class files 107 are stored (e.g., in temporary or permanent storage) on server 100, and are available for download over network 101.
Client platform 102 contains a virtual machine (VM) 111 which, through the use of available native operating system (O/S) calls 112, is able to execute bytecode class files and execute native O/S calls when necessary during execution. An example interaction between the client platform and the server is the request and response in HTTP (hypertext transport protocol). HTTP is a commonly used method for transferring HTML (hypertext markup language) documents, a type of web pages, across the Internet.
As Java™ class files are often referenced to within an HTML document, requests for HTML documents often trigger the transfer of compiled Java™ classes as well. For example, when a browser application executing on client platform 102 requests an HTML document, such as by forwarding URL (universal resource locator) 109 to web server 108, the browser automatically initiates the download of the class files 107 identified in the HTML document. Class files 107 are typically downloaded from the server and loaded into virtual machine 111 individually as needed. The virtual machine locates and loads each class file, parses the class file format, allocates memory for various components of the class, and links the class with other already loaded classes. This process makes the bytecode in the class readily executable by the virtual machine. An example of the entire class loading process is the use of applets on web pages. A user may request a web page via his browser. Embedded on the page is a reference to a game applet. Upon receipt of the request by Server 100, the applet is downloaded to the browser along with the page. The applet is then loaded onto the Virtual Machine 111 on the user's computer (Client 102) and executed. The user can then begin to interact with the applet just as with any programs on his computer.
Plug-In Development
There is a mechanism for developing plug-ins in a platform independent programming language. For instance, pluglets are plug-ins developed in the Java™ programming language. FIG. 2 shows an example of an existing implementation of Pluglet in the browser environment. Within FIG. 2 are several Application Programming Interfaces (APIs). API refers to a collection of software modules available for use. An API declares the behavior of the collection so programmers can understand how to use the software modules within an API and whether different APIs are compatible with one another.
In FIG. 2, Pluglet API 200 interacts with Pluglet Engine 210, which allows the Java based Pluglet API 200 to interact with the C++ based Browser Plug-in API 230 via Java Native Interface (JNI).
Thus Pluglet Engine 210 serves as an intermediary between Pluglet API 200 (in Java™) and Browser Plug-in API 230 (in C++). Pluglet Engine 210 also handles calls to Open JVM Interface (OJI), which plays the role of the Java Virtual Machine (JVM) that is required for the execution of Java bytecodes found in Pluglets.
One of the main drawbacks of a such a system depicted in FIG. 2 is the reliance on native interfaces such as Java Native Interface (JNI). Considerable development effort is needed to develop an interface similar to Pluglet Engine 210 for each type of browser. To develop each interface, new modules called wrapper codes must be implemented using JNI to connect the native programming language of the browser with the programming language of pluglets. The development process of wrapper codes is often a tedious and error prone process. There are also performance concerns. For example, during the execution of the pluglets on the Solaris environment, using JNI requires two copies of JVM to be stored in run-time memory. This takes up memory resources of the system and slows execution.
BlackConnect and XPCOM
XPCOM (Cross Platform Component Object Model) is a technology that allows software components written in various programming languages to communicate with one another within the browser environment. XPCOM is available as part of Mozilla™ browser project. BlackConnect technology was developed to enable software components written in Java™ to take advantage of XPCOM. With BlackConnect and XPCOM, Java components can communicate with other software components written in various programming languages within the browser environment. The combination of BlackConnect and XPCOM greatly enhances the efficiency of the software development process. For example, a game programmer developing in Java™ can take advantage of an existing graphic rendering engine component written in C++, instead of creating such component himself in Java™.